docs/install: add xCAT provisioner with rocky10/almalinux10 recipes - #2654
docs/install: add xCAT provisioner with rocky10/almalinux10 recipes#2654viniciusferrao wants to merge 1 commit into
Conversation
📦 Package Count Analysis ResultsEnvironment: UBI 10 Container 🏭 Factory RepositoriesStatus: ✅ Factory repositories analysis completed successfully
Analysis performed by OpenHPC Package Count CI |
🚀 CCache Statistics
📊 Detailed StatisticsopenEuler (aarch64)openEuler (x86_64)RHEL (aarch64/gnu15)RHEL (x86_64/gnu15)RHEL (x86_64/intel)🤖 Generated from workflow run |
Test Results 29 files 29 suites 53s ⏱️ Results for commit f9c0647. ♻️ This comment has been updated with latest results. |
|
I most likely will not be able to review to this until after PEARC and PTO (Mid Aug), but will try. Thoughts on integrating stateless and stateful into one doc? We do something similar in Warewulf for provision-to-disk. |
Stateful is not ready yet. I wanted to finish that for the next TSC meeting be not sure yet. Still testing the steps. But the idea was to file another PR. If we will merge in a single one, I would need to redo it. If that's the approach let me know that I will start the rework instead of finishing the stateful part. |
|
The general idea is to merge the two recipes, not have two separate ones - and that would be best as a single PR. I don't quite understand why there would be two. If they really need to be two recipes (very different workflow) then that's fine - it just seems odd (I've not looked at the previous xcat or used xcat in the past). Also note that there will be considerable testing to get it to actually get it working on our testing environment so doing both at once would be good. |
|
A friendly reminder that this PR had no activity for 30 days. |
|
I need to get the stateful back on track. I procrastinated due to the cancellation of next meetings. |
1155a79 to
68b41e2
Compare
68b41e2 to
6ac4ba1
Compare
|
@middelkoopt At first I wasn't though it was a good idea, however I was able to merge both stateless and stateful in a single recipe. It required some replacement of information but it looked fine in my opinion, in chapters 5 and 7. In fact it's way better now. |
6ac4ba1 to
d7f638d
Compare
Adds xCAT to the Markdown recipe system, covering both of its provisioning
modes in a single guide. The mode is chosen at run time by ${xcat_mode} in
input.local rather than at document build time, so one guide and one
recipe.sh serve both, matching how the Warewulf recipe handles
provision-to-disk:
stateless compute nodes boot a RAM-resident image built in a chroot on
the head node
stateful a base OS is installed to each node's local disk, then OpenHPC
components are added to the running nodes
A "Select Provisioning Mode" section defines shell functions -- compute_exec,
compute_install, compute_group_install, compute_upgrade, compute_clean -- that
act on the image chroot when stateless and on the running nodes via xdsh when
stateful. The shared customization chapters call those helpers and are
otherwise untouched, so the InfiniBand, Omni-Path, memlock, GPU, syslog,
oneAPI and admin-tool sections are written once rather than once per mode.
Functions rather than variables because ${CHROOT} is only known after genimage
runs, and a function re-resolves it at call time.
Mode-specific steps live in templates/provisioner/xcat/ as stateless-* and
stateful-*, gated with ohpc_if so the generated script takes one path. Both
forked chapters group that work under a single heading -- "Stateless
Provisioning"/"Stateful Provisioning" and "Stateless Deployment"/"Stateful
Deployment" -- following the same aggregator-owns-the-grouping-header pattern
as "Cluster Admin Tools", so a reader follows one group and skips the other
outright. Nothing mode-specific sits outside those headings.
The deploy chapter starts Slurm on the head node first. Stateless nodes boot
afterwards and their slurmd reaches the controller on the first try, while the
already-running stateful nodes are then told to start theirs.
Details worth noting for review:
- The mode is a value, not a boolean. Every other input.local flag named
enable_* turns an optional feature on or off, but this selects a mandatory
mode, so it is spelled xcat_mode=stateless|stateful rather than a lone
enable_stateful with no counterpart. It fails closed: anything else aborts,
so a half-configured input.local cannot quietly netboot a fleet meant to
install to disk.
- Image lookup refuses to guess. A head node holding images for several
distributions or releases matches more than one, so the recipe stops unless
exactly one matches or ${xcat_osimage} names it, and the chosen image is
checked against the mode by its provmethod before anything is modified.
- The stateful wait requires every node to positively report a finished boot
and to have lost a marker written to /run before the reset, so neither an
unreachable node nor the system being replaced counts as ready. It gives up
after ${install_timeout} rather than waiting forever on a failed install.
It proves a reboot, not a successful install: a failed PXE attempt falling
back to the existing disk would pass. Proving the install would need a
per-run token written from the kickstart.
- The upgrade appendix spells out xdsh and --installroot commands per mode and
re-derives ${CHROOT}, because the helper functions above exist only in the
installing shell.
Both modes were deployed end to end on AlmaLinux 10.1 with xCAT 2.18.2 and two
compute nodes: the recipe ran start to finish in each, nodes provisioned to
tmpfs and to local disk respectively, Slurm showed both nodes idle, and a
two-rank MPI job ran across them.
Signed-off-by: Vinícius Ferrão <ferrao@versatushpc.com.br>
d7f638d to
f9c0647
Compare
'An corp' xCAT stateless guides for OpenHPC 4.x with EL10 systems.
Sponsored-by: VersatusHPC